-
-
Notifications
You must be signed in to change notification settings - Fork 33k
gh-135676: Reword the f-string (and t-string) section #137469
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: Blaise Pabon <[email protected]>
Co-authored-by: Adam Turner <[email protected]> Co-authored-by: Blaise Pabon <[email protected]>
Co-authored-by: Stan Ulbrych <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for taking a while to review this. I started adding lots of detailed comments, but have abandoned that for now, because my overall feeedback took shape at a higher level -- I don't think lexical analysis is the right place for large parts of this content. For example, explaning the detail of how replacement fields work necessarily references expressions, which we haven't yet covered in the PLR, as we're still notionally in the tokenising/lexing phase.
From the introduction of the chapter, 'This chapter describes how the lexical analyzer breaks a file into tokens.', and I think we make a mistake by trying to cover/explain all of f-strings here.
I wonder if there is a clear enough distinction we can draw between the lexing of f-strings (that could go into lexical_analysis
, the parsing & grammar thereof (that could go into e.g. expressions
(?)), and the runtime evaluation of the AST, e.g. how format specs are evaluated (that could go into stdtypes
?)
I think there are bits of the treatment & grouping that are somewhat nebulous and could go either way, but I'd prefer to be stricter with the content in the Language Reference, even if that means splitting up the coverage of f-strings into a few places.
I'd be happy to work up a PR with something closer to my suggested split if it'd be useful, but otherwise let me know your thoughts.
A
When you're done making the requested changes, leave the comment: And if you don't make the requested changes, you will be put in the comfy chair! |
The question is: Does this PR bring the docs closer to the desired state? Would you be OK with basing your PR on this rather than the status quo? I did try to move runtime stuff to |
This PR addresses #125496. I've closed that issue in preference to this one. |
Continuing from #135942, this tackles the f-string section.
Much of the information was duplicated in
stdtypes.rst
; this PR keeps lexical/syntactical details in Lexical Analysis and the evaluation & runtime behaviour in Standard types, with cross-references between the two.Since the t-string section only listed differences from f-strings, and the grammar for the two is equivalent, that section was moved to Standard types almost entirely.
📚 Documentation preview 📚: https://cpython-previews--137469.org.readthedocs.build/